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VIRTUAL CIRCUrrS IN PACKET NETWORKS 
Field of the Invention 

This invention relates to packet netwoite, for example Internet Protocol (IP) networks, and 
more paxticiilariy to automatic and dynamic provisioning of virtual circuits within packet 
6 networks so as to provide Quality of Service (QoS). 

Background Art 

QoS generally refers to the provision of a guaranteed data throughput level in a network, such 
as a guarantee to a customer that end-to-end latency will not exceed a specific level. The 
provision of QoS guarantees with respect to packet networks is critical for congestion 
10 sensitive traJBBc such as VoiceA^ideo over Packet (VoP) or Voice/Video over IP (VoIP) 
traffic. Consumers axe increasingly turning to Internet telephony as an alternative to more 
traditional forms of commimication as users realize the potential economic benefits associated 
with this form of communication. However, the lack of QoS has impaired the widespread 
growth and acceptance of this form of communication. 

15 QoS in conventional packet networks is typically provided by manually configuring 
switching elements such as network switches and routers, or by using specialised signalling 
protocols or packet schedxilers. This is disadvantageous in terms of efl&ciency, useability, 
scalability and cost. 

Summary of the Invention 

20 The present invention includes a system for provisioning a virtual circmt having a 
predetermined Quality of Service (QoS) within a packet network having a network topology 
comprising a pliu^lity of nodes selectively intercoimected via a plurality of links, the system 
comprising: at least one circuit client connected to the packet network, the circuit clirat being 
operable to generate a virtual circuit request representing a request for a packet flow between 

25 a pair of nodes at the predetennined QoS; and at least one circuit manager connected to the 
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packet network, the circuit manager being operable to receive the virtual circuit request from 
the circuit client and process the virtual circuit request using a route selection algorithm and a 
Connection Admission Control (CAC) algorithm to identify at least one route through the 
network topology satisfying the virtual circuit request; wherein the circuit manager 
5 dynamically and individuaUy configures the nodes to set up a virtual circuit on the identified 
route for the packet flow betweea the pair of nodes at the predetermined QoS. 

The present invention also includes a method for provisioning a virtual circuit having a 
predetermined QoS in a packet network having a network topology comprising a plurality of 
nodes selectively interconnected via a plurality of links, the method comprising the steps of: 

1 0 generating a virtual circuit request representing a request for a packet flow between a pair of 
nodes at a predetermined QoS; processing the virtual circuit request using a route selection 
algorithm and a CAC algorithm to identify at least one route through the networic topology 
satisfying the predetermined QoS; and dynamicaUy and individually configuring the nodes to 
set iq) a virtual circuit on the identified route for the packet flow between the pair, of nodes at 

15 the predetennined QoS. 



Brief Description of the ]>rawing 

Embodiments of the invention will now be desciibcd, by way of exai^le only, with reference 
to tibie accompanying drawing in which: 

Figure 1 is a schematic diagram of an exemplary architecture for a system for provisioning a 
virtual circuit having a predetennined QoS in accordance with an embodiment of the 
invention; 

Figure 2 is a schematic diagram of the system architecture of Figure 1 partitioned into two 
circuit domains; 



25 



Figure 3 is a schematic diagram of architectural components for virtual circuit management in 
the system architecture of Figures 1 and 2; 
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Figure 4 is an illustratiaxi of an exexnplaiy virtual circuit between source-destination 
endpoints; 

Figure 5 is a schematic diagram of a client/server model where service is betwem client and 
server; 

5 Figure 6 is a schematic diagram of a client/servrer model where service is between two clients; 

Figure 7 is a schematic diagram of a client/server model with a server proxy; 

Figxire 8 is a schematic diagram of a SIP Circuit Client Module (SCCM) in accoxdance with 
an embodiment of the invention; 

Figure 9 is a circuit state flow control diagram of the SCCM of Figure 8 in passive mode 
10 operation; 

Figure 10 illustrates a first exemplary SIP call flow usiiig the SCCM of Figure 8 in passive 
mode operation; 

Figure 1 1 illustrates a second exemplary SIP call flow using the SCCM of Figure 8 in passive 
mode operation; 

15 Figure 12 illustrates a third exemplary SIP call flow using the SCCM of Figure 8 in passive 
mode operation; 

Figure 13 illustrates a fourth exercplary SIP call flow using the SCCM of Figure 8 in passive 
mode operation; 

Figure 14 is a circuit state flow control diagram of the SCCM of Figure 8 in either active or 
20 passive mode operation with codec filtering; 

Figure 15 is a circuit state flow control diagram of the SCCM of Figure 8 in active mode 
operation; 
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Figure 16 iUustrates a first exeniplary SIP caU flow using the SCCM of Figure 8 in active 
mode operation; 

Figure 17 illustrates a second exemplary SDP call flow using the SCCM of Figure 8 in active 
mode operation; 

Figure 18 is a schematic diagram of an exemplary SIP system with two SIP enc^oints; 

Figure 19 is a schematic diagram of an Wemplaiy implemeaatation of a SIP server proxy with 
a third jiaity SIP system; 

Figure 20 is a schraiatic diagram of an alternative exemplary implementation of a SCCM 
integrated as a SIP server proxy with a third party SIP server; 

Figure 21 is a schematic diagram of an exemplary single-site system for provisioning a virtual 
circuit having a predetermined QoS in accordance with an embodiment of the invention; 

Figure 22 is a schematic diagram of an alternative exemplary single-sitc system for 
provisioning a virtual circuit having apredetOTOiined QoS in accordance with an embodiment 
of the invention; and 

Figure 23 is a schematic diagram of an exenqilary multi-site system for provisioning a virtual 
circuit having a predetttmined QoS in accordance with an embodiment of the invention. 

Detailed Description 

Embodiments of the system for provisioning a virtual circuit having a predetemiined QoS 
according to tiie present invention are designed to support the establishment and operation of 
virtual circuits between user q)plications operating over packet networks, such as IP 
networks. Among other parameter?, a virtual circuit has end-to-end behaviow characterised 
by a guaranteed bandwidtii and statistically bounded packet transfer delay. The general 
system architecture for virtual circuits is described below. 
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Viitual Circxiit System Architecture 

RefeiTing to Figure 1, the system architecture of the prefeired embodiment of the present 
invention is comprised of a set of network components which include switching elements 
100, endpobt access nodes 102 and numerous interconnecting links. The switching elements 

5 100 and the endpoint access nodes 102 may generically referred to as nodes. Switching 
elements 100 are devices that can be further characterised as a switch or a router. Switches 
deliver datagrams from one physical port to another without change to the datagram. An 
example of a switch switching element is an Ethernet switch. In contrast to switches, routers 
do not change the payload of a packet, instead routers dcUver datag ra ms from one physical 

10 port to another by swapping the Media Access Control (MAC) address (or other identifier 
type) before emitting the datagram at the egress port. An example of a router switching 
element is an IP router. The system is characterised as a set of n switching elements or nodes 

100 F-{^„^„..J^/,}. 

Links are physical connections that provide connectivity between switching elements 100 and 
15 between switching eleihents and endpoint access nodes 102. A switch link in the system is 
defined as an ordered pair of switches (NuNj) if and only if there exists a physical connection 
. between Ni and Nj in the switch set V. Thus, the system can be fiirther characterised as being 
comprised of a set of links £. Associated with each switch link (N,.Nji is a link capacity By 
and a circuit utilisation factor denoted by the parameter/^ that represents Hie maximum 

20 fraction of that link's edacity that can be used for virtual circuits- 
Typical IP networks consist of Routing Domains or subnets (or subnetworks). Each node or 
network clement (whether they be switching dements or user access nodes) is defmed as 
belonging to a Routing Domain or subnet if they share a common portion of their IP address 
according to a subnet mask. Routers have the fimction of interconnecting Routing Domains. 

25 Therefore, links can be fiirther characterised as Routing Domain links, switch links or 
oadpoint access node links. 
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A link is a Routing Domain link if link(^.,A^p e £ , and both Nt^Nj^ V are router switching 

elements. A link is a switch link if link (/ST,, iS/^^) e L and either if N^^NJ e Fare both switch 

switching elements or one is a switch switching element and one is a router switching 
element A link is an enc^int access node link if an end^oint access node is physically 
5 connected XoN.^V . Endpoint access nodes can be any one of the following four types: 

1 . User Access Nodes (Uj) 102. 

2. Circuit Domain Manager Node (CDH) 104. 

3 . Circuit Network Manager Node (CNMj) 1 06, 

4. Circuit aient Nodes (CCm) 108. 

10 Each of flie four types of endpoint acce^ nodes will be e^lained below, after descxibing 
virtual circuits within the context of the data plane and management plane of the system 
architecture. 

The system data plane architecture described below provides an abstract framework within 
ixiuch the circuit functions provided by network componmts can be defined. 

15 A virtual circuit flow is the sequence of packets transported over the virtual circuit. Each 
packet of a virtual circuit flow that airives at an ingress port of a switching element 100 has 
associated with it flow characteristics defined in terms of a quadruplet denoted by 
FC^{l,Jo*PR,RT) (Equationl). 

The parameter /; in Equation 1 is the ingress flow identifier. Thie ingress flow identifier // 
20 consists of two parameters (P/, i7». Pi is the physical port number of the switching element 
that the virtual circuit flow is entering and ITj is the Identifier Type of the virtual circuit flow 
appealing at the ingress. The IT can include but is not necessarily limited to one of the 
following: 
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1) defined as an IEEE 802.3ac VLAN tag. 

2) iVfPXuS defined as a multiprotocol label switching label. 

3) />5'CP defined as a differentiated services (diflfserv) code point value. 

4) L4 defined as an tip to IP layer 4 address (layer 4 addresses can be made null or 
5 . '•wild"). 

Thus rr can be expressed zsH G\yZAN,MPLS,DSCP,LA\ (Equation 2). and // can be 
expressed as = (ij, - 

In Eqxjation 1, the parameter is the flow identifier that is to be assigned to the virtual 
circuit flow at the egress port on which it is emitted from the switching element as a result of 
10 routing or switching in the switching node. lo consists of two parameters (Pes ITo)- Po is the 
physical port number of the switching element jfrom which the virtual circuit flow is emitted 
and Uo is the Identifier Type, as defined in Equation 2, assigned by the switching element to 
the virtual circuit flow at the egress. Thus, lo can be expressed as - (P^, /T^) . 

The parameter PR in Equation 1 is the priority assigned for scheduling packets identified by // 
.15 or /oat the egress port Po- 

In Equation 1 the parameter RT is the policing rate applied at the ingress to packets identified 
by //. The policing rate enables the proper allocation of bandwidth (such as by dit5>ping 
packets or marking them down to a different QoS level) and can be set at ntdl policing. 

The behaviour of switching elements for virtual circuit flows is defined in terms of the 
20 routing or switching of packets from an ingress port P/ to an egress port J^o, the mapping JTi 
-^IToy the scheduling priority aud, if not null, the enforcement of a rate limit defined by RT. 
In addition, if packets with Identifier Type ITi appear at an ingress port other than P/ then it is 
preferable that the switching eleoaent unconditionally discard those packets. 
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A virtual circuit can now be formally defined by the following. 

1. A User Access Node source IP address that identifies the start point of the virtual 
circuit 

2. A User Access Node destination IP address that identifies the endpoint of the virtual 
5 circuit 

3. A set of flow characteristics VC = {FC^,FC2, ,FC^}that provides connectivity 

between the source and deistination User Access Nodes 102. The flow characteristic 
associated with the switching element attached to the start point of the virtual circuit 
(i,e- jFC/) must specify a policing rate RT other than nxill policing. Defining a set of 

10 flpv/ charactmstics in this way effectively pins flie route of virtual circuit traffic flow 

and packets in that flow are processed with the appropriate priority and/or service 
class along the route. The route traverses m switching elements 100 and involve 
(m+/) links of which (m-/) are switch links or Routing Domain links and two are 
endpoint access, node links. The nuking ITj ITo of a flow as it traverses from 

15 ingress to egress port in eadi switching element 100 permits aggregation of flows 

&om different virtual circuits over selected links in the network. 

By defining a virtual circuit in this way and applying the switching element behavioivs 
described above allows for virtual circuits to exhibit virtual circuit characteristics. Virtual 
circuit characteristics ^ply to virtual circuit flows and are defined in terms of a triplet 
20 denoted by VCC = {BTV^ ,MD,a) . B is the bandwidth throughput fiom the source User 

Access Node to the destination User Access Node, The policing rate RT specified in the flow 
characterisdc associated with the switching element attached to the start point of the virtual 
circuit must be made greater than or equal to BW^iax' The parameter MD is the maximum 
end-to-oid delay that packets belonging to a virtual circiut flow will undergo, and the 
25 parameter a is the quantile of delay, vdxich is the probability that MD will be exceeded during 
the virtual circuit^s lifetime. 
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The circuit management function witbin the system architecture ensures that virtual circuits 
are defined appropriately, such that they exhibit virtual circuit characteristics. The following 
section deals with the management plane of virtual circuits. 

Refeiiing to Figure 1, virtual circuits are controlled by a functional entity referred to as a 
5 Circuit Manager (CM) (not shown in Figure 1). The CM accepts virtual circuit set up and 
release requests received from the Circuit Client Nodes (CC) 108 and provides the virtiial 
circuit functionality within the systotn. For scalability, the CM functions are partitioned into 
Circuit Network Manager Node (CNM) 106 functions and Circuit Domain Manager Node 
(CDM) 10^ functions, as shown in Figures 1 and 2. The partitioning and functions of the 
1 0 CNM 106 and CDM 104 will now be described. 

In terms of the management plane, the system architecture is logically partitioned into 
sections referred to as "circuit domains." A circuit domain is comprised of one or more 
Routing Domains or subnets. For example. Figure 2 shows the network of Figure I 
partitioned into two circuit domains. Circuit Domain A 200 and Circuit Domain B 202. 

1 5 Circuit Domains A 200 and B 202 each encompass a set of switching elements 100 belonging 
to the subnets contained in the circuit domains 200. 202 and these will be controlled by a 
single CDM 104. The CDM 104 is responsible for resource allocation and virtual circuit set 
up and release within a single circuit domain and any outgoing inter-CDM links. The CNM 
106 is aware of all Routing Domain links that interconnect circuit domains in the syston and 

20 coordinates the CDMs 104 controlling the domains by establishing circuit segments across 
each domain. These interconnected segments form the end-to-onid virtual circuit. The 
combination of a CNM 1 06 and the CDMs 1 04 provides the CM fimctionality . 

the CNM 106 may be co-located with a CDM 104 or may be hosted on a separate platform. 
Multiple CNMs 106 may exist in the network since the CDM 104 is responsible for resource 
25 allocation. A minimal system may contain a single CNM 106 and CDM 104, 



Figure 3 shows the architectural components for virtual circuit management by the Circuit 
Manager 300 and the AppUcalion Program Interfaces (APIs) 302, 304, 306, 308 between 
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them. The APIs 302, 304, 306, 308 themselves are not described because it will be 
appreciated that they may be implemented, using a variety of known methods, as a series of 
con^uter instructions embodying all or part of the functionality described herein. 

The virtual circuit system architecture described above shows the use of flow characteristics 
5 sets to define a virtual circuit In the preferred embodiment of the invention, the flow 
characteristics mappings and transforms, allowed for in the system architecture, provide a 
basis on which to design scalable and efficient networics. 

The mapping Pi -^Pq of a, virtual circuit flow independent of other virtual circuit flows or 
non-virtual circuit flows allows for the efficient use of network resources. The appropriate 

10 choice of tibiese ingress and egress port mappings and the switching elements' ability to 
provide the mqypings gives rise to the possibility of achieving a higih grade of service (or low 
virtual circuit blocking probability) within the network- 
Examples of IT and P xzKappings in achieving these goals will be discussed below wi& 
specific reference to the use of the L4, DSCP and MPLS Identifier Types, hi these examples 

1 5 the following assumptions are made. 

1 . Switches are capable of making only the following TT mappings: 

a. £4-^ DSCP 

b. L4'^MPLS 

c. MPLS^U 

20 2. Switches can only perform port mappings of virtual circuit flows independent of other 
virtual circuit flows or non-virtual circuit flows when they are associated with MPLS 
Identifier Types. That is, switching elements carmot "switch" based on ihz DSCP or 
specific Layer 4 definitions. 
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The moping by Ciiciiit Managers 300 to set up virtual circuits between souirce-destiaatlon 
endpoints is discussed bdow by reference to Figure 4. 

Circuit Managers 

Consider a virtual circuit between the soiirce endpoint 400 and die destination endpoint 418 
6 as shown in Figure 4. At the request of a Circuit Client, not shown in Figure 4, the Circuit 
Manager 300, also not shown, is responsible for detenxiining a suitable route for the virtual 
circuit fhrough the network. The undeclying requirements for route selection is its correctness 
in so much as the route , must start at the correct source 400 and temiinate at the correct 
destination 418 and deliver the specified virtual circuit characteristics associated with the 

10 virtual circuit. In tenns of starting and ending at the correct points in the network, there are 
three routes possible between the indicated source^destination nodes in Figure 4 and are 
shown as heavy 406, intermediate 408 and light 410 dasjbied lines. How the Circuit Manager 
300 decides which of these routes to choose is a function of the routing algorithm 
implemented, which in turn is a function of the performance criteria requirements imposed on 

15 the network- Although the **optimum*' route meets some imposed performance criteria (say 
mixumising hop count as with the heavy dashed line 406), it may ,not be able to satisfy tibie 
specified virtual circuit characteristics (no available capacity on the Router A 402 to Router B 
404 link, for example). In this case an alternate, non-optimum route (say the intermediate 
dashed line 408) could be considered if the specified virtual circuit characteristics could be 

20 met on this route. This would avoid the virtual circmt being blocked on the "optimum"' path, 
thus improving the grade of sendee the network can offer. To achieve a high grade of 
service, it is a desirable feature of the network for the Circuit Manager 300 to be able to 
choose either of the three routes 406, 408, 410 shown in Figure 4 independent of any other 
virtual circuits or non-virtual circuit traffic that has previously been admitted between the 

25 same source-destination pair. The prefeanred manner for achieving this is through the use of 
MPLS labd switched paths (LSP). The use of LSPs for this purpose is discussed below. 

Once the route is chos^o, the Circuit Manager 300 is able to define the Pi Pq mappings at 
each switch along the virtual circuit's path. The Circuit Manager 300 is then required to 
specify a set of flow characteristics, one for each switching element on the chosen route. 
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Flow characteristics specify the ingress and egress flow identifiers and infonnation regarding 
the priority and policing of the virtual circuit packets. In general the priority associated with 
virtual circuit jQlows is always set to the highest priority and the policing parameter is set to 
NULL at each switching node except at the ingress switching node where it is set to a value 
5 greater than or equal to the bandwidth of the virtual circuit specified at circuit set-up. 

Without loss of generality, it is assumed that the virtual circuit flow is identified by a L4 
Idoitifier Type at the source ingress into the network (denoted as ITsouret) and it is a 
requirement (unless othermse stated) that iqpon exit of the netwoiic at the destination node, 
the flow possesses this same L4 Identifier Type (denoted as ITdestbiatian) with the possible 
1 0 exception cf the preservation of the DSCP contained in the IP packet header. 

llxe case where only the use of the L4 Identifier Type is used to set-up the end-to^nd virtual 
circ\iit is now considered. It should be pointed out that in this case, the only P/ Pq 
mappings available are those already specified in the individual switching elements 
switching^routing tables for the source/destination IP addresses in the Z4 Identifier Type 
15 definition. These pre-existing switching/touting table entries can be set via &e infomiation 
provided by such protocols as the Spanning Tree Protocol (for inira-Routing Domain 
switches) or Open Shortest Path First (for inter-Routing Domain routers). In any case, once 
set, all IP datagrams are switched or routed according to these entries whether they are part of 
a virtual circuit flow or otherwise. 

20 As shown in Figure 4, an example of a virtual circuit route is specified by fiie heavy dashed 
line 406 (i.e., switch A-1 420 /switch A-2 422 /router A 424 /router B 426 /router 02 428, 
router D-E 430 /switch E-1 432 /switch E-2 434 /switch E-3 436). This virtual circuit was 
established by the Circuit Manager 300 by defining die /Tjource — > JTd€s^&on mapping and 
configuring the switch elements* associated priority and policing settings. 

25 Taking the specific exanople shown in Figure 4 the procedure that would be followed when 
using DifFserv techniques is described below. Before effectively using Diffserv techniques 
the following pre-requisites apply. 
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1 . All traffic entering the network (but not including traflBc between switches) must have 
its DifiGserv codepoint value {DSCP) vdthin the IP packet header reset to nuU or zero 
by the ingress switching element This is usually achieved by a one-off configuration 
setting on the switching element This is reqinred since en<^oint applicatiojis have the 
5 ability to set ttxe DSCP to arbitrary values. To use the DSCP ejBEectively for traffic, it 

is a requirement that Ae Circuit Manager 300 be able to set the DSCP uniquely for 
virtual circuit traffic oxily. 

All switching elements are set to prioritise traffic based on the value of &e DSCP 
within the BP packet header. For example, packets with a DSCP of z&m are assigned 
the lowest priority at the switching elements output queue while they are assigned the 
highest priority when the DSCP take on a specified non-zero value. The DSCP of 
101 1 10 is recommended for this puxpose, TTxese priority settings arc usually achieved 
by a one-off configuration setting on tibie switching element 

With the pre-requisites in place, the Circuit Manager 300 need only assign a L4-> DSCP 
1 5 Identifier Type mapping at the ingress switch 420 (i.e., switch A-1) with the associated virtual 
circuit policing rate. No other network elements need configuring. This represents a 
significant reduction in configuring switching elements for virtual circuit set-up i^iien 
compared with Layer 4 techniques. 

When Diffserv is used, switching elements switch or route packets as normal, according to 
20 their switching/routing table entries except that all switching elements are configured to map 
packets with the virtual circuit JDiSCP to the Mghest priority output queue Iw^ 

Taking the specific example shown in Figure 4, the procedure that would be followed when 
using techniques, taking advantage of the labeling characteristics of MPLS to create an 

index to a predefined routing table fliat defines the next hop, is described below. Using the 
25 MPLS technique in accordance with the present innovation requires the configuration of a 
predefined Label Switched Path (LSP) which is a specification of the label switched path 
through which the virtual circuit traffic traveises. The LSP can be defined along the entire 
end-to-md circuit or only a segment of that circuit For example, using the network shown in 



2/ 
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Figure 4, for end-to*end use of MPLS, the Circuit Manager 300 could define a LSP from 
switch A-1 420 through to switch E-3 436 along any of the three routes 406, 408, 410 shown 
in the jBgure. In addition, the switches must be configured to prioritise MPLS traffic at the 
highest priority level on LSPs used for virtual circuit tiafiBc. 

5 With the pre-requisites in place, the Circuit Manager 300 need only assign a L4^ MPLS 
Identifier Type moping at the ingress switch 420 (i.e., switch A-1) with the associated virtual 
circuit policing rate. At the egress switch 436 (i.e., switch E-3) the Circuit Manager 300 
would assign a MPLS-^ L4 Identifier Type mapping to remove the MPLS label (the MPLS 
label could be lejft in place if the exit to the virtual circuit network was an MPLS capable 
10 network). No other network elements need configuring. This represents a sigaificant 
reduction in configuring switching elements for virtual circuit set-up when coicpared with 
I^yer 4 techniques. 

When LSPs are used, switching elements switch or route packets according to the MPLS 
labels so no finther configuration is required. The implications of this are that the route for 
15 virtual circuit traffic can be differentiated firom the route for non-virtual-circuit or other 
existing virtual circuit traffic. When tibie LSP does not extend along the entire circuit route, 
then all switching elements on the circuit route, but not on the LSP, must be configured as 
described above. 

When there is a need to reduce the complexity associated with MPLS and the creation and 
20 maintenance of LSP, it may be desirable to limit the use of MPLS to only certain parts of the 
virtual circuit network. In the remaining parts of the network, a combination of Layer 4 and 
Diflfeerv techniques can be used. Taking the exanople of Figure 4, consider the following 
scenario. 

L The case where virtual circuit blocking within Routing Domains (where routing is 
25 fixed for all traffic) is considered very low; Here the use of the Diffserv technique 

within Routing Domains would Bpply and its use would be considered beneficial since 
it reduces the management of intra Routing Domain switching elements. 
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2. The links interconnecting Routing Domains may be considered a more scarce resoiuce 
and tbe adoption of MPLS techniques is desirable for QoS reasons. TTie creation of 
"permanent" LSPs between routers that could be used by the Circuit Manager 300 for 
circuit creation would be more maintainable than if LSPs were required throu^out 
5 the entire network. For the network presented in Figure 4, a total of 20 LSP 

definitions would be required to provide a fully meshed set of LSPs from one louter to 
every other router. 

^ If the above case were implemented, then the Circuit Manager 300 could configure a circuit 
JGrom source to destination as follows: 

10 1 . Assign a L4 DSCP Identifier Type mapping at the ingress svdtch 420 (i.e., switch 

A-1) with the associated virtual circuit policing rate. No other network elanents 
within Routing Domain A needs configuring. 

2. Assign 9,14 -> MPLS Identifier Type mapping at Router A 424 wljere the MPLS label 
corresponds to a LSP that terminates at Router D-E 430. No other loutexs along the 

.15 LSP need configunng. 

3. Assign a MPLS -> L4 Idoxtifier Type mapping at Router D-E 430 to remove the 
MPLS label. The resultant hayer 4 flow wiU have preserved the DSCP set at the 
ingress switch A- 1 420, From here the layer 4 flow with DSCP set to correspond to a 
virtual circuit flow will be delivered by the switches in Routing Domain E 4 16 to the 

20 required destination. 

Circuit Clients 

Circuit CUent Nodes (CCs) 108 are entiUes that request and estabUsh virtual circuits between 
User Access Nodes within a network via the Circuit Manager API 304, as illustrated in Figure 
3. The system architecture aUows flexibiUty in locating CCs 108 within the network as 
25 described below. 
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Circuit Clients 108 can be embedded into User Access Nodes 102 that xise the Circuit 
Manager API 304 to establish virtual circuits between itself and other remote User Access 
Nodes 102. The remote User Access Nodes 1 02 need not be Circuit Clients 108 themselves. 

Stand Alone Circuit Clients establish virtual circuits between User Access Nodes 102 that are 
5 not themselves Circuit Clients 108. Stand Alone Circuit Clieats obtain the necessary virtual 
circuit parameters required to establish the circuit via manual entry by a human operator. An 
example of this type of a Stand Alone Circuit Client is a Command Line Interface (CLI) that 
uses the Circuit Manager API 304. In this case, the operator is prompted to enter the 
appropriate parameters to establish the required virtual circuit. The Stand Alone Circuit 
10 Client is appropriate for setting up static or semi-permanent virtual circuits between User 
Access Nodes 102 that are not Circuit Clients 108, for example between a disk array and 
backup system. 

Now referring to Rgure 5, there are many cases where signalling occurs between a Circuit 
Client and Server to initiate and provide a particular service. Figure 5 shows the case where 

15 the service is between a single Circuit Client 500 (Client), in response to Service request 502, 
and Server 504, resulting in service delivery 506, such as with streanodng video applications or 
network gaming ^iplications. Figure 6 shows the case where a Server 504 is used to establish 
a 5ession(s) between byo Circuit Clients (client A 600 and Client B 608) such as with IP 
telephony or video conferencing applications. Under these Client/Server models, the service 

20 request phase consists of the Clients 600, 608 and Server 504 negotiating all aspects of the 
media to be transferred as well as specifying the network and transport connection attributes 
by which the media will be transferred through the network. During this phase all the 
necessary information required to set up and tear down virtual circuits between the Clients 
600, 608 can be derived or gathered explicitly at the Server 504 end It is possible, therefore, 

25 to locate either of the Circuit Clients 600, 608 at the Sender 504 utilising the application level 
signalling protocol information for establishing virtual circuits. These Server 504 located 
Circuit Clients 600, 608 are similar to the Stand Alone Circuit Clioats but where the virtual 
circtiit parameters required to establish the virtual circuit is obtained via some third party 
signalling protocol rather than via a human operator. The benefit of the Server 504 located 
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Ciicoit Client 600. 608 is that the Circuit Manager API 304 is not required to be supported at 
the Clients 600, 608 for the establishment of virtual circuits. 

In some system architectures it may also be possible to include a Server Proxy 700 as shown 
in Figure 7. For this case it is possible to locate a Circuit Client at the proxy 700 to the Servw 
5 504 rather than the Server 504 itself as described above, the benefit of this approach over the 
Server located Circuit Client is that the Circuit Manager API 304 is not required to be 
supported at the Client or Server 504 for the establishment of virtual circuits. In this way 
^ virtual circuit technology can be incoiporated in networks that have pre-existing services 
obtained from thud party vendors. 

10 Circuit Clients that rely on third party signallixxg protocols can be further characterised as 
being passive or active. Passive Circuit Clients do not modify the content or alter the 
sequence of the signalling between Circuit Client and Scarver 504 based on the outcome of 
virtual circuit establishment process, vs^ereas active Circmt Clients caia modify the content or 
alter the sequence of this signalling. Active Circuit Clients arc useful when it is undesirable 

1 5 for sessions to proceed when the network is unable to provide virtual circuit characteristics to 
the data flow. 

circuit Clients may also be implemented directly or indirectly in architectures in -wbich a 
multimedia manager, such as an DP-PBX system, is provided to control packet flow signalling 
between endpoints. For example, an IP-PBX performs the following steps in processing a 
20 call between two IP telephones. 

1 . Call signalling: An IP telephony device sends a request to tixe IP-PBX to ori^nate the 
call. The request contains flie address (phone number) of the destination to be called. 
The IP-PBX locates the called party, sends a new call event to the called device, and 
waits for the called device to respond with an answering ev^L 



25 



2. Media control: "When tibie caUcd device answers, the IP-PBX determines the details of 
the media session to be established. The IP-PBX must ensure that the two devices can 
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coramiinicate with a common voice-encoding scheme, and it must provide each device 
with the IP address and port on which the other device has chosen to receive media. 

To generate a virtual circuit request between the two IP telephones, the Circuit Client taps off 
data from the IP-PBX that is representative of the actual packet jttow signalling. Hie IP-PBX 
5 data processed by the Circiiit Client to generate a virtual circuit request can include but is not 
necessarily limited to the following: 

1. Local IP address of the terminal. 

2. Local IP port of the temxinal'sRTP channel, 

3. Incoming RTP packet size in millisecond. 
10 4, Codec type of incoming media. 

5. Remote terminal's IP address. 

6. Remote terminal's RTP IP port 

7. Outgoing RTP packet size in millisecond. 

8. Codec type of outgoing media. 

15 Exen^lary implementations of Circuit Clients using Session Initiation Protocol (SIP) 
signalling are described below. It will be appreciated that Circuit Clients may also be 
implemented using any packet data protocol that allows for an admission control function 
partly or wholly based on requested and available bandwidth, for exaxx^)le H.323 signalling. 

SIP is an application-layer control protocol defined by the Internet Engineering Task Force 
20 (IETF) for use in multimedia commimications over IP networks such as Internet telephony 
calls, multiroedia distribution, and multimedia conferences. The protocol is defined in BBTF 
RFC 326 L SIP: Session Initiation Protocol, June 2002. 
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To enable virtual circuit functionality witiiin a SIP system, the Circuit Client can be 
integrated into the SEP system. This is facilitated by a logical component known as SIP 
Circuit Client Module (SCCM) to manage the interface betweoa the Circuit Client and the 
SIP protocol , stack. The SCCM performs all the virtual circuit operations based on the 
5 incoming and outgoing SIP messages. However, the SCCM does not need to be integrated 
into every component within the SIP system. 

The possible options in interfacing a Circuit Client within the SIP architecture are outlined 
below. The methods in interfacing the Circuit Client in both passive mode and active mode 
axe also discussed below. 

10 As shown in Figure 8> the SCCM 800 is a logical entity that consists of the following three 
components: Circuit Client lOS; Mediator 806; and SIP protocol stack 808. The Mediator 
806 is the heart of the SCCM 800. It is responsible for iI]itia^dng the virtual circuit sei up and 
tear down operations via the Circuit Client 108 based on the SIP messages received fix>m 
and/or sent to the SIP protocol stack 808. The default behavioxir of the Mediator 806 is as 

15 follows: 

1 . intercept SIP messages from the TCPAJDP protocol stack; 

2. process the SIP messages; and 

3. pass on the SIP messages to the SIP ^plicatioxt 

The responsibilities of the Circuit Client 108 and SIP protocol stack 808 components are to 
20 encode and decode circuit signalling and SIP signalling messages respectively. 

The SCCM 800 shown in Figure 8 is situated between two SIP endpoints 810, 812, This 
allows the SCCM 800 to gain full control over the SIP signalling. Full control of the SIP 
signalling is required if the SCCM 800 needs to manipulate the SIP signalling such as 
terminating the SIP calls when no circuits are available between the endpoints concerned. 
25 Moreover, in order to set up and tear down virtual circuits for each SIP session, the SCCM 
800 must 
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1 . intercept all the caller endpoint's SIP request 8 1 8 messages; and 

2. intercept all the SIP response 820 messages to the caller endpoint's request messages. 

The SCCM 800 can be operated in a passive mode or an active mode. In passive mode, the 
SCCM 800 does not terminate the SIP session if there is no virtual circuit available between 
6 two endpoints concerned. Conversely, the SCCM 800 terminates the SIP session if there is 
no available virtual circuit between the two enc^ints concerned when operating in active 
' mode. The two operating modes arise due to service reqxdreraents. Some service providers 
may prefer to let calls through even if there is no virtual circuit available. That is, they would 
prefer to offer best effort service instead of no service. 

10 In passive mode operation, the SCCM 800 does not terminate the SIP session when no virtual 
circuit is available between the two SIP endpoints 810, 812 concerned. A possible 
implementation of the SCCM in passive mode is shown in Figure 9. The media negotiation 
shown in Figure 9 is based on the offer/answer Session Description Protocol (SDP) model as 
this must be supported by all SIP endpoints according to the SIP standard. The SDP model is 

15 described in IETF RFC 3264, An Offer/Answer Model with the Session Description Protocol 
rSD/V, June 2002. 

Figure 9 shows the jflow of circuit state and the execution of virtual circuit set up and tear 
down operations based on the SIP messages received by the SCCM 800 for a SIP session. In 
addition, atypical call flow between two SIP endpoints with virtual circuit operation is shown 
20 in Figure 10 and Figure 11. Figure 10 shows the case in which the offer/answer SDP pair is 
embedded in the INVITE/OK message pair, while Figure 1 1 shows the case in which the 
virtual circuit operation failed when the offer/answer SDP pair is embedded in the OK/ACK 
message pair. 



25 



Operation duneouts are handled by both the Circuit Client 108 and the SIP application via the 
SIP protocol stack 808. If any operations timeout, then they will be conveyed via the FAIL or 
ERROR responses fix>m either the Circuit Client 104 or SIP protocol stack 808 respectively. 
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Referring to Figure 9, the ciix:uit is in the idle state 900 initially. Whenever a SEP INVITE 
message is received, the Mediator (not shown in Figure 9) checks whether the INVITE 
message contains any offer SDP message 902, If it does, then the circuit proceeds to the 
ready state 904, otherwise the circuit wQl be in Ihc waiting state 918. According to the SIP 
5 standard, the ofifer/answer SDP pair must be CTbedded within cither tiie INVITE/OK 
message point of Figure 1 0 or the OK/ACK message pair of Figure U . 

When the answer SDP to the offer SDP is received 906, the circuit proceeds to the create 
^ state 908. If not, the circuit proceeds 922 to the idle state 900. In the create state 908, the 
Mediator 806 detomines the bandwidth 910 required based on the codec negotiated between 
10 the two SIP endpoints concerned and proceeds to set up the virtual circuit with the Circuit 
Manager 300 via the add circuit operation 912 of the Circuit Client 104 conq>onent shown in 
Figure 8. If the circuit set up operation is successful, then the circuit proceeds to the 
connected state 914; otherwise the circuit reverts back 924 to the idle state 900. 

During the ready 904 and waiting 918 states, the Mediator 806 is waiting to receive more SIP 
15 messages 926. In either of these two states, tibie SIP session may be terminated via the 
CANCEL^ BYE, or ERROR message from either the callee endpoint 1000, caller end^int 
1002 or its own SIP protocol stack 808, If tibiis is the case, then the circuit reverts back to the 
idle st2Lte 900, 

The Mediator 806 may receive a BYE, ERROR or re-INVITE message from either endpoint 
20 when the circuit is in the connected state. In the case of a BYE or ERROR message, such 
message signifies the termination of the SIP session. Thus, the Mediator 806 would tear 
down the virtual circuit that is created via the Circuit Client*s 108 remove circuit operation 
916.. The circuit then reverts back to the idle state 900. 

In the case of a re-INVITE message, it signifies the . modification of the existing media 
25 channels such as to renegotiate the codec used and/or set up more media channels. In this 
case, the Mediator 806 creates a temporary circuit and proceeds through the above process 
again. Only if the temporary circuit is in the connected state will the old circuit be deleted 
and any information associated with the old circuit state (e.g., circuit ID) be updated with that 
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ioibnnation associated with the temporary circuit state (this is not shown in Figure 9). On the 
other hand, if the re-INVlTE session is successful while the new circuit set up operation fails, 
then an existing SIP session may lose its established circuits. 

Call flow for a successM re-INVTTE session with circuit set up operation is shown in Figure 
5 12 and Figure 13. Figure 12 shows the case in which the offer/answer SDP pair is embedded 
in the INVITE/OK message pair, while Figure 13 shows the case in which the circuit 
operatio0 failed when the offer/answer SDP pair is embedded in the OK/ACK message pair. 

During the bandwidth determination stage, if the bandwidth calcidation is based on the 
information available within the SDP messages, then the mediator needs to maintain a 

1 0 mapping of the codec type to maximum bandwidth required for all supported codec types. 
This is because the codec type is the minimum codec information provided by the SDP 
message. On the other hand, if the mediator has access to the RTP media channels, then the 
bandwidth calculation can be performed based on the RTP media channels' settings. In the 
case of unsiqxported codec types, the mediator will not attempt circuit set up and allow the 

1 5 SEP call session to proceed as normal. 

Depending on the service requirements, encountering unsupported codec types can be 
avoided during the circuit set up stage via restricting the SIP call set up scenario. The SCCM 
800 can prevent itself from encountering unsupported codec types during the cixcuit set up 
stage by filtering out all the unsupported codec types in the caller's offer SDP before passing 
20 it to the callee. If all &e codec types have been jBltered, then the circuit set up operation 
would be tenxunated and the offer SDP should be reverted back to the unfiltered SDP, 

If codec filtering is incorporated into the SCCM 800, then the SCCM 800 would be operating 
in an active mode of operation as the embedded SDP messages may be modified. Figure 14 
illustrates the incoii)oration of codec filtering 1400 into the initially proposed implementation 
25 shown in Figure 9, 

The active mode SCCM 800 is described below as an extension to passive mode SCCM 800 
with additional call temiinatipn functionality. 
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As illustratBd in Figure 15, in active mode operation, the SCCM 800 tominates the SIP 
session 1500 when no circuit is available between the two enc^ints concerned. That is, the 
SCCM 800 may modify SIP signalling of an existing SEP sessioij. The simplest 
implementation of this mode of operaUon is to extaid the passive mode SCCM 800 shown in 
Figure 9 by incorporating a call termination module. Implementation of the circuit 
teimination procedure is highlighted in Figure 16 and Figure 17. Figure 16 shows the caU 
flow with circuit termination for a SIP session in which the offer/answer SDP is in the 
INVrrE/OK message, while Figure 17 shows the case in v»*dch the offer/answer SDP is in the 
OK/ACK message. 

If any of the codecs negotiated were not suppprted, then the whole SIP session would be 
teiminatcd. To avoid unsiqjported codec types during the circuit set xsp stage, codec filtering 
can be incorporated as mentioned in the previous subsection. This implementation with 
codec filtering is shown in Figure 14. 

Figure 18 shows a typical SIP system where two SIP endpoints 810, 812 are communicating 
with each other. Since the SCCM 800 is a logical component, it can be implemented as an 
independent software library. Hms Ubrary cast then be integrated into existing SIP 
implementations to enable cirouit fimctionality. 

Within the SIP architecture, the SCCM 800 can be integrated into the foUowing SIP entities: 

1. theSIPoodpointsSlO, 812; 

2. the SIP application server 1802 (such as. SIP marshal sender, SIP gateway server etc); 
and/or 

3. the SEP server proxy 1800. 
These are discussed in turn below. 

Either of the SIP endpoints 810, 812 are possible points of integration for the SCCM 800, 
Both the passive mode and active mode SCCM 800 with codec filtering extension can be 
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supported at this point of integration. The next possible point of integration of the SCCM is 
the SIP application server 1802. Integrating the SCCM 800 into the SIP application server 
1802 means that ihe SCCM 800 can piggyback onto the SIP application server's 1802 
security mechanism for authenticatipn purposes. 

5 The SEP server proxy 1800 is another point of integration for the SCCM 800. Moreover it 
may be the only possible point of integration for the SCCM 800 within an existing third party 
SIP system. Note thai the SIP server proxy 1800 is basically a SIP message forwarder ftiat 
receives SIP messages from one point and passes tiiexn on to the next point 

Integrating the SCCM 800 into the SIP server proxy 1800 has the following features: 

10 1 . requires a "once-off ' effort in implementing the SIP proxy server 1 800; and 

2. implementation of this SIP proxy server 1800 is isolated (decoupled) from third party 
SIP endpoint or application server implementation. 

In addition, the beihaviour of the SIP server proxy 1800 within the SEP architecture is well 
defined by the SIP standard. 

15 The SIP server proxy 1800 is only required to intercept the outgoing requests and incoming 
responses between the caller endpoint and the third party SIP application server 1802 as this 
reduces the number of SIP messages needed to be handled by the SIP server proxy 1800. 
That is, the outgoing requests and incoming responses between the third party SIP application 
server 1802 and the callee endpoint 812 can be allowed to bypass the SIP server proxy 1800. 

20 This scenario is shown in Figure 19 and Figure 20. 

Figure 19 shows the deployment of a SIP server proxy 1800 with a tihird party SIP system in 
which the SIP server proxy 1800 is the first point of contact for all SIP caller endpoints 810. 
Figure 20 illustrates the SEP server proxy 1800 as the fii^ point of contact from all SIP callee 
endpoints 812. Either configuration allows the SDP server proxy 1800 to gain full control 
25 over the routing of SIP messages. In cither case, the SIP server proxy 1800 must set the 
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Record-Route field on all SIP request messages 820 to easure diat all the coirespoading returu 
SIP response messages 818 are received by the SIP server proxy. 

Both the passive and active modes with codec filtering ^tensions can be integrated into the 
SIP proxy server 1800, 

5 Virtual Circuit Connection Admission Control 

An exemplary connection admission control algorithm to perforai the virtual circuit set up is 
described below. 

The iiq>uts required to perform the virtual circuit connection set up function are as follows: 

1. Network topology. The network administrator can manually enter in the networic 
10 topology. Alternatively, information regarding the topology of the network can be 

dynamically derived from information obtained from nodes wittiin the network. The 
information is contained in the various Management Information Bases (MIBs) 
maintained within nodes that relate to how nodes arb interconnected. From this 
infomiaiion.the topology can be dynamically derived via an algorithm. Examples of 

15 typical node MIBs used for this pxcpose are those defined in. RFC 1493 and RFC 

12 13. The network topology is represented by a gr^h G(V, E) consisting of two sets 
of objects called nodes (or switches) and edges (or linksX with each edge defined as 
an ordered pair of vertices. A vertex / is adjacent to a vertex j in the vertex set F if 
(ij) is an edge in the edge set The edge (ij) is incident wifli the vertices i andy. 

20 Associated with each edge or link (ij) is a link c^aci^^^. 

2. A globally unique index that identifies the virtual circuit cormection and given by the 
integer circuUIndex, 

3. The location of the endpoints of the virtual circuit connection. The source and 
destination endpoints are characterised as being at vertices sourceVertex and 

25 destinationVertex within the vertex set F, respectively. 
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4. The peak bandwidth of the virtual circuit connection. This requested bandwidth is 
denoted as circuitBandwidth, 

5, Hie maximum value of qucixing delay allowable for the connection denoted as 
circuitMaxDelay, The value for this parameter may be derived from some delay 

5 budget calculation. 

6. The quantile of queuing delay denoted as circuitDelayQuantile indicating the 
probability that the delay circuitMaxDelay will be exceeded should not be greater than 
CircuitDelayQuantile, The value of this parameter is application specijBic. 

7, The parameter^^ associated with each link (I J) that represaits the maximum fraction 
10 of that link's capacity that can be used for virtual circuit connections. 

The outputs of the virtual circuit connection set up function are as follows: 

1. A path or route for the virtual circuit connection. The route is deficned as a sequence 
of vertices P starting at the vertex attached to the source endpoint, such that each 
vertex is adjacent to the preceding and following vertices in the sequence, and no 
15 vertex repeats and ends at the vertex attached to the destination enc^int The number 

of hops in the route is denoted as circuitHopCount, 

-2. The actugJ queuing delay for the virtual circuit connection. This is denoted as 
circuitDelay and can be used for de-jittering purposes. 

3. A function return status indicating the virtual circuit connection has been successfully 
20 admitted or otherwise. 

The inputs required to perfonn the virtual circuit connection release function are as follows: 



1. 



The route for the virtual circuit connection that is to be released 
as a sequence of vertices P. 



The route is defined 
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2. The peak bandwidth of the virtual circuit coimection that is to be rdeased and is 
denoted as circuitBandwidth. 

The output of the virtual circuit connection release function is a function return status 
indicating the connection has been successfully released or otherwise. 

5 For each litik {ij), a state variable Bcoipj is maintained and is equal to 4e aggregate 
bandwidtfi already conunitted to virtual circuit connections on the link (iJ). 

When a virtual circuit connection is to be set \q>, the following procedure applies: 

1. Determine a route P between 50Mrcererfex and <fes/ma/<onFerr€xen<^ This can 
^ *>oe by using Dijkstra's algorithm for the shortest path or Martins' algorithm to 
.10 calculate the k shortest paths between any two nodes in a network. Martins* algorithm 

is described in E. Q. V. Martins et al„ ♦The K shortest paths jproblem," Research 
Report, CISUC, June 1998. If a route is determined, the connection is conditionally 
"b" admitted, else the connection is rejected and the functidh rehnn status is set to 
FALSE. ■ • 

15 2. The connection is conditionally "c" admitted if for every link (i, j) on the specijSed 
route P 

CircuitBandwidth + B^^ i,^ fy^B„ 

otherwise the connection is conditionally rejected. If the connection is conditionally 
rejected, eliminate this route j6om the Ust of available routes, mark the connection as 
20 conditionally "a" admitted and repeat step l. If this step is satisfied then the 

parameter circuitHopCcunt can be deterroined from the route. 



. Detennine the queuing delay for tilie route found in st^ 2 from the following 
equation: 
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^chauiMayQu^ = MctrcuuHopCouni + Ptir^opCc^ {drcuUDeloyQuantUe) x o-^ram^c^t 
where 



M^uB^ccunt = circuitHopCount 



^ci'^^mvcc-t ^CircuitHopCount 



\U(i-/_)J 



5 where is defined as inax{/j^) V(/,y) in i>, and where the wei^ting 

^^^^^ Pr^atrvadcfiHepcomdi^"^ is Calculated for given values of 

CircuitHopCount and circuitDelqyQuantile. 

The queuing delay calculated using the above equation is normalised to the service 
time of one packet. The most conservative value of queuing delay (in seconds) is 
10 given by fibie following equation: 

where MTUJSize is the maximum transfer unit size in bits, and B„un is given as 
min{^^}v(i,y) isxP. 

The connection is conditionaUy rejected if the delay bound, estimated usixsg the 
equation immediately above, on the chosen route exceeds circuitMaxDelay. If the 
connection is conditionally rejected, this route is elinunated fix>m the list of available 
routes, and the connection is marked as conditionally "a" admitted and step 1 is 
repeated. If the delay bound circuitMaxDelay is satisfied the connection is 
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unconditioiiaUy '*d" admitted, and the value of circuitDelcQ^ is set to the actual value 
of the queuing delay obtained from the equation immediately above. 

Once a virtual circuit connection is unconditionally ""d"' admitted into the network, for each 
link (hj) oti the specified route P the state variable BC0IP j is updated as follows: 

and the:%mction return sUtus is set to TRUE. 
Exenq>lary Virtual Circuit Networks 

Exan:5>les of how Circuit Clients (CCs) 108. Circuit Domain Mangers (CDMs) 104 and 
Circuit Network Manageis (CNMs) 106 can be used within the virtual circuit system 
10 architecture framework to implement single and multi-site virtual circuit networks are 
discussed below. - ; 

The single site topologicial model consists of a single site or campus. Figure 21 depicts a 
typical exapDple of a small single site network 2114 within a building 2102, In the exanq>le 
shown in Figure 21, telephony calls are served by a SIP proxy/call manager that has been 
15 incotporated into a CC 108 and calls outside the campus are served by an IP-to-FSTN 
gateway 21 12. For small deployments such as these, only a single CDM 104 and CNM 106 
is required to manage virtual circuits throughout the network. In this single CNM/CDM 
106/104 case, a sunomaiy of the sequence of events required for successful virtual circuit 
establishment is as follows: 

20 1 . The CC 108 sends requests for virtual circuit set up to tihie CNM 106. 

2. Upon receiving virtual circuit requests from the CC 108, the CNM 106 requests from 
the CDM 104 a virtual circuit segment throug^h the network. 

3. The CDM 104 is responsible for the topology discovery, resource management and 
allocation for virtual circuit set up and release. Upon specific requests for new virtual 
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circuits, the CDM 104 perfoims route determination and Connection Admission 
Control (CAC) functions based on the individual virtual circuit bandwidth 
requirements and the current state of the network- When these functions arc 
successfully completed, the CDM 104 perfonns all of the necessary switching element 
5 configurations required to support the new virtual circuit The CDM 104 then signals 

back success to the CNM 1 06. 

4. Upon receiving success notification firom the CDM 104, the CNM 106 perfonns the 
final part of the CAC process by calculating tihe delay bounds for the new virtual 
circuit If tibis is Mdthin acceptable limits ^e CNM 106 informs the CC 108 of 
1 0 success, completing the virtual circuit set up process. 

It can be seen that the amount of state information that the CDM 104 is required to ga&er and 
maintain and the amount of processing it is required to perform for each virtual circuit set-up, 
can become very large as the network size increases. Where single site networks are larger in 
size it will be necessary to form multiple circuit domains that are managed separately. 

15 A typical example of a large single site network 2208 with Circuit Clients 108 that si^port 
SIP telephony and H323 video conferencing services within a building 2102 is depicted in 
Figure 22. In this example the netwoik 2208 is logically partitioned into two circuit domains^ 
A 2202 and B 2204, For each circuit domain there is a CDM 104 that is responsible for 
resource allocation and virtual circiut set up and release only within its domain and any 

20 outgoing inter-CDM links. In this case» a single CNM 106 is used which is aware of the two 
CDMs 104 and the links that connect ifaem. Virtual circuit requests are received by the CNM 
whereby it will coordinate the relevant CDMs 104 controlling the circuit domains by 
establishing circuit segmoats across each domain. These interconnected segments fonn the 
end-to-end virtual circuit. Partitioning the netwoik in this way distributes both the storage 

25 state information and the processing required for virtual circuit set up and release. 

For the specific netwoik shown in Figure 22. consider the example where the CNM 106 
receives a circuit request between two endpoints 2206 contained within a single circuit 
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domain, A suitunary of the sequence of events xeqnired for successful virtual circuit 
establishme:at for this case is as follows: 

1. Upon receiving the virtual circuit request firom the CC 108, tibie CNM 106 recognises 
that the virtual circuit endpoints are contained within a sixxgle circuit domain. The 
CNM 106 requests firom the single relevant CDM 104 a circuit segment between the 
nominated endpoints. 

2. The CDM 104 performs all the necessary functions to admit the new circuit and the 
CNM 106 is notified of success. 

3. Upon receiving success notification from the CDM 104, the CNM 106 performs the 
final part of the CAC process by calculating the delay bounds for the; new virtual 
circuit If this is within acceptable limits the CNM 106 informs the CC 108 of 
success, completiag the virtual circuit set up process. 

For the specific network shown in Figure 22, consider flie example where tlie CNM 106 
receives a circuit request between two endpoints 2206, one endpoint in each of the two circuit 
domains 2202, 2204, A smnmaiy of the sequence of events required for successful virtual 
circuit establishment for this case is as follows: 

L Upon receiving the virtual circuit request from the CC 108, the CNM 106 recognises 
that one virtual circuit endpoint is within circuit domain A 2202 and the other is 
within circuit domain B 2204. The CNM 106 is aware of the intercoimecting links 
between circuit domains and upon choosing an appropriate link does the following: 

a. Requests from the CDM 104 in circuit domain A 2202 a virtual circuit 
segment between the nominated endpoint in circuit domain A 2202 and the 
chosen inter-circuit domain link; and 

b. Requests jBrom the CDM 104 ia circuit domain B 2204 a virtual circuit 
segment between the chosen inter-circmt domain link and the nominated 
endpoint in circuit domain B 2204. 



wo 2005/013562 



PCT/AU2004/001037 



-32- 

2. Upon receiving success notification from both CDMs 104 the CNM 106 performs the 
final part of the CAC process by calculating the delay bounds for the new end-to-end 
virtual circuit. If this is within acceptable limits the CNM 106 informs the CC 108 of 
sucpess, completing the virtual circuit set up process. 

5 Using multiple CDMs allows the management of virtual circuits to scale to very large size 
networks, since as the network size grows, it is a matter of creating new circuit domains 
. managed by additional CDMs. 

The multiple-site topological model consists of multiple sites or campuses. A ^ical 
example of a multi-site network is depicted in Figure 23 where there axe three remotely 
1 0 located branch offices. 

In this multi-site model the branches of the network are intercoimected via some suitable 
WAN VPN 2300 infrastructure that is capable of siq>porting real-time applications. In terms 
of establishing a virtual circuit network that incozporates the tibiree branch ofBces 2302, 2304, 
2306, one option would be to establish three circuit domains, one located at each of the 

15 branch offices with a corresponding CDM 104 controlling all the resources located at that 
branch office (of course, the use of multiple CDMs can be used at the individual branch 
offices as discussed above). In this specific example, and as far as a CNM 106 is concerned, 
the network consists of three circuit domains intorconnected by some (virtual) links 
characterised by some fixed cs^acity and delay porformance. These iiiter-QDM links will be 

20 CGianaged by die CDMs 104 in the same way as physical links intercoxmecting switching 
elCTaents 100. 

For the particular scenario shown in Figure 23, it is important to consider the nse of multiple 
CNMs in order to establish fast and efficient virtual circuit, set \xp and release. Consider the 
specific case where only a single CNM 106 was deployed and was located at Branch Office C 
25 2306. If a CC 108 at Branch Office A 2302 requested a virtual cnuuit with source/destination 
en(^oints both located at Branch Office A 2302; the circuit request would need to traverse the 
WAN VPN 2300 to the CNM 106 at Branch Office C 2306. Dqpending on the type and span 
of the WAN VPN 2300, this would result in considejable signalling overheads across the 
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WAN links. In this case it is better to employ a CNM 106 at each branch location. If this 
were done (as shown in Figure 23) then for the case where a Circuit Client at any branch 
QjBRce requested a virtual circxiit with source/destinadon endpoints both located at the same 
branch office, then no signallixxg is required to traverse the WAN VPN 2300 resulting in fast 
and efficient circuit set up and release. Only when virtual circuits are required that extend 
between branch offices will virtual-circuit-related signalling be required to traverse the WAN 
VPN 2300. Even in this case the signalling required for end-to-end virtual circuit set up is 
completed within a single round trip. 

For multi-site topologies, the use of multiple CNMs allows the virtual-circuit-related 
signalling to be minimised across WAN VPN 2300 links resulting in fast and efficient virtual 
circuit set up and release. 

It will be apparent firom the above description that preferred embodiments of the present 
invention at least provide the following. 

1 . End-to-end quantifiable and verifiable service guarantees to packet flows. 

2. Automatic and dynamic configuration of network switching elements as and when 
ajpplications require guaranteed service. 

3. Virtual circuit set up and tear down using common ^plication level signalling 
protocols. There is no requirement for user endpoints or applications to support any 
special protocols or prioritisation techniques. 

4. Effective isolation between virtual circuit and non-virtual-circuit traffic. Network 
switching elements need only s\q>port simple prioritisation and policing functionality. 

5. Dynamic end-point and topology discovery. 

6. Centralised control of netwoik resources enables the CM to be able to give advanced 
warning of heavily used links or hot spots in the network so that necessary action can 
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bc taken to re-dimension links or add/replace network components before service 
problems eventuate. 

7. Scalability to large size networks through the use of Dififserv and/or MPLS 
aggregation techniques. 

5 The embodiments of the invention have been described by way of example only and 
modifications are possible within the scope of the invention* For example, while the 
embodiments have been described in the context of the SIP protocol, the invention is not 
limited to that protocol. It will be appreciated that the invention may be implemented in any 
packet data protocol that allows for an admission control function partly or wholly based on 
1 0 requested and available bandwidth, for example the H.323 piotocoL 

Throughout the specification, uixless the context requires otherwise, the word **comprise^' and 
variations such as "comprises" or "comprising," will be understood to imply the inclusion of 
a stated integer or group of integers but not the exclusion of any other integer or group of 
integers. 
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